Las actividades de validación y negociación de requisitos persiguen asegurar que los requisitos alcanzan unos adecuados niveles de calidad relacionados con el acuerdo entre las partes implicadas.
Es necesario comprobar periódicamente que la especificación sigue siendo acorde con las necesidades de clientes y usuarios, y compatible con los objetivos de la organización.
Durante las actividades de ingeniería de requisitos es necesario revisar periódicamente la calidad de los requisitos.
La validación de requisitos es el proceso de verificar que los requisitos definen claramente el sistema que verdaderamente quiere el cliente. Está fuertemente relacionada con las actividades de análisis, pues trata de evitar problemas, retrasos y sobrecostes.
Las actividades más relacionadas con la calidad del producto son las pruebas.
Las pruebas de aceptación son las que relacionan el producto con la especificación inicial.

El Desarrollo Dirigido por Pruebas es un estilo de programación en el que se entremezclan: codificación, pruebas unitarias y diseño (refactorización).
Tiene mucho sentido en modelos iterativos de desarrollo con pequeños incrementos.
En el Desarrollo Dirigido por Pruebas, son las pruebas quienes guían el desarrollo del código.
Escribir una prueba que verifique la implementación de la siguiente funcionalidad que se va a incluir en el software.
Codificar la funcionalidad de manera progresiva e incremental hasta conseguir que la prueba se ejecute sin problemas.
Refactorizar el código para mejorar su estructura interna.

Ventajas:
Mejora la calidad del código.
Aumenta la cobertura de las pruebas.
Reduce el tamaño del código.
Mejora el diseño.
Validación: garantizar que estamos construyendo el producto correcto.
Verificación: garantizar que el proceso de construcción es correcto o que se construye correctamente.

La validación de requisitos se encarga de garantizar una adecuada calidad en la especificación desarrollada, evitando problemas en etapas futuras del proceso de desarrollo.
Para asegurar que se realiza una buena validación de requisitos, conviene recordar cuáles son las tres dimensiones fundamentales en la ingeniería de requisitos:
Contenido (content): conocer todos los requisitos de manera explícita y comprenderlos con el nivel de detalle requerido.
Acuerdo (agreement): establecer un nivel de acuerdo suficiente sobre los requisitos entre las partes implicadas.
Documentación (documentation): documentar y formalizar todos los requisitos según los formatos definidos.

| - Completitud - Trazabilidad - Corrección - Consistencia - Independencia de la implementación - Verificabilidad - Necesidad | - Estandares - Comprensible - Conformidad de los lenguajes | - Acuerdo de stakeholders - Resolución de conflictos |
Involucrar a los stakeholders adecuados, recomendable que el auditor no coincida con el analista.
Separar las actividades de identificación y corrección de errores: primero realizar la identificación y después la corrección.
Validar desde diferentes enfoques.
Emplear diferentes estilos de documentación.
Construir artefactos: prototipos, pruebas, diseños...
Validar de manera periódica, ya que las necesidades y las especificaciones evolucionan y la duración del proyecto puede ser larga.
Las técnicas de validación de requisitos con conocidas por el término genérico de revisiones.
Las revisiones pueden ser:
Informales: consisten en simples charlas entre el equipo de desarrollo y los clientes o usuarios.
Formales: el analista guía a un equipo de revisores, analizando el enunciado de cada requisito y explicando las implicaciones de cada uno de ellos.
Actividades previas a la revisión: consiste en preparar y planificar la revisión, definiendo el equipo, determinando el tiempo, eligiendo un lugar y distribuyendo la documentación.
La reunión de revisión: no debe superar las dos horas, un miembro dirige el proceso y otro se encarga de registrar las decisiones y acciones a tomar.
Actividades posteriores a la revisión: se analizan los errores y conflictos detectados para proceder a la corrección y mejora del documento.

Autor o dueño: analista que ha generado la documentación y será el encargado de corregir los errores.
Inspector o auditor: personas encargadas de encontrar errores, omisiones o inconsistencias.
Lector: encargado de presentar el documento a la audiencia.
Director o moderador: gestiona el proceso.
Secretario: anota los resultados.
El autor comparte sus requisitos con un colaborador para obtener retroalimentación.
Se trata de una técnica que puede aplicase de manera individual o en grupo y constan de las siguientes fases:
Planificación: determinar el objetivo, los participantes y el resultado esperado.
Resumen: el autor presenta un resumen a los participantes.
Detección de errores.
Recolección de errores y consolidación: documentar los problemas detectados.
Se trata de una versión reducida de la técnica de inspección. Se van presentado los requisitos a los inspectores.
Se trata de evaluar los requisitos elaborados desde diferentes perspectivas. Esta técnica se aplica en combinación con inspecciones o walk-throughs.
Perspectiva del cliente o del usuario: funcionalidades deseadas.
Perspectiva de arquitecto: ver si es posible el diseño.
Perspectiva del tester: se pueden generar casos de prueba.
Perspectiva del contenido: calidad de los requisitos.
Perspectiva de la documentación: calidad formal.
Perspectiva del acuerdo: ausencia de conflictos.
Los prototipos son una técnica muy adecuada para que los auditores tengan una primera experiencia del posible resultado esperado según la especificación desarrollada. Este método es la manera más efectiva para identificar errores en los requisitos.
Para realizar la validación prepararemos antes los siguientes elementos:
Instrucciones
Escenarios de validación
Lista de comprobación con criterios de validación
Las listas de comprobación (checklist) consisten en la realización de un cuestionario sobre aspectos concretos de los requisitos.
Verificabilidad de los requisitos.
Consisten en diseñar pruebas asociadas a los requisitos durante el proceso de validación de la especificación.
La generación de pruebas en etapas iniciales del desarrollo, permite corregir:
Omisiones de escenarios, identificando todos los caminos de ejecución.
Nuevos requisitos funcionales a partir de nuevos caminos de ejecución.
Problemas de ambigüedad.
Una de las prácticas más recomendadas es TDD (Test Driven Development).
Durante los procesos de elicitación, análisis y validación de requisitos, pueden surgir conflictos entre las partes implicadas que será necesario resolver.

Identificación del conflicto: Atender las causas que pueden originar conflictos.
Análisis del conflicto: Analizar la razón del origen y definir el tipo.
Conflicto de datos. Información incompleta, incorrecta, difusa...
Conflicto de intereses. Objetivos contrapuestos.
Conflicto de valores. Dependen del origen de los stakeholders.
Conflicto de relaciones. Relaciones personales.
Resolución del conflicto.
Documentación de la resolución del conflicto: Una vez resuelto el conflicto, debe quedar correctamente documentado. Si no es así, podemos encontrar algunas amenazas:
El conflicto puede volver a aparecer.
La resolución encontrada puede demostrar ser inapropiada.